Adversarial review — PR #1612

Two-day-old PR, reviewed against canary, with cross-PR context from #1608. Findings below; CI failure analysis at the bottom.

BLOCK — conflicts with PR #1608 (delete autostart script)

tools/scripts/windows-setup-autostart.ps1 is being deleted by PR #1608 (open since 2026-06-11, conflicting). The deletion rationale, in #1608's own words:

• Registers a SYSTEM scheduled task that "popped a visible terminal window on every login — the malware playbook signature"
• Brought up vEthernet (WSL) before NlaSvc/WMI finished enumerating real Wi-Fi → Settings>Network freeze on a fresh HP Omen 5090
• "Silent SYSTEM-level scheduled tasks … erode trust … even when the code is benign"

This PR's section 6 ADDS to that condemned script. Net effect of merging both: rebase conflict, and either:

• feat(install): provision prereqs + fail-fast robustness (CUDA, firewall, Git Bash guard, node/npm checks) #1612 wins → the firewall rule lives in deleted code (dead) OR the malware-pattern script gets resurrected, OR
• fix(windows): delete autostart script — it looked like malware and froze Settings>Network #1608 wins → this PR's firewall logic vanishes

Resolution required: either (a) hold #1612 until #1608 is decided and relocate the firewall rule onto whatever replacement install path emerges (per #1608 the replacement is wsl.conf [boot] inside the distro — no Windows-side autostart at all), or (b) explicitly close #1608 first. Don't merge #1612 with the firewall block intact while #1608 is open.

RISK — -Profile Any on the airc inbound rule is too broad for a dev laptop

New-NetFirewallRule … -Program $aircExe -Protocol TCP -Profile Any

Any = Public + Private + Domain. A developer who sets up auto-start on a laptop then takes it to a coffee shop is now accepting inbound airc TCP from anyone on the public AP. The intent (grid routing between owned nodes) is Private/Domain only.

Fix: -Profile Domain,Private (or document why Public exposure is intentional).

RISK — CUDA toolkit auto-install fires without explicit user opt-in

install_cuda_toolkit is a 3GB silent download triggered any time nvidia-smi reports a GPU. The header docstring announces the install at top, but for a user who clones to peek at the code and runs bash tools/scripts/install.sh on their NVIDIA laptop expecting a quick "from-source" build, this is a surprise 3GB download with sudo prompts.

Fix: prompt before fetching the keyring (Y/N with default N in interactive mode), or honor a CONTINUUM_SKIP_CUDA=1 env-var bypass and advertise it in the YELLOW "will install CUDA toolkit" line during detect_gpu.

RISK — rust-toolchain.toml pin is workspace-wide and unrelated to PR title

This PR's title is about install-script changes; pinning the toolchain to 1.92.0 across the entire workspace is a substrate-affecting change that deserves its own PR (or at minimum its own commit and a sentence in the PR description). The justification (continuum-core ICEs on >= 1.93 for x86_64-linux) is plausible but unverified by reviewers without an issue link / reproducing build log.

Fix: either split into its own PR with the ICE reproduction log, or add the issue link / CI run that reproduces the 1.93 ICE.

NIT — stale "from-source" path in error messages

Header (line 19) correctly says cd continuum && bash tools/scripts/install.sh. But the in-script error text still points to the old layout:

• Line 31: Usage: bash scripts/install.sh
• Line 175: cd src && bash scripts/install.sh (in the CAN_SUDO=false branch of install_cuda_toolkit)

A fresh-Linux user who hits the "no terminal for sudo" path follows that hint to a nonexistent path. Fix to cd continuum && bash tools/scripts/install.sh.

NIT — Git Bash guard prompt could be friendlier

The windows-shell branch says:

✗ This is Git Bash / MSYS on Windows — not a Linux environment.

A first-time user who downloaded the repo and double-clicked Git Bash because that's what their muscle memory does on Windows won't know that "MSYS" means them. The redirect to WSL2 / install.ps1 is good; consider leading with the redirect ("Run install.ps1 instead, or open a WSL prompt") rather than the technical distinction. Minor; not blocking.

CI: carl-install-smoke (linux/amd64) is a pre-existing failure, not caused by this PR

Verbatim failing log line:

🦀 continuum-core: Core IPC types (code, persona, rag, ipc, memory, voice, data)
   ❌ Failed: exit=null signal=null
❌ Some bindings failed to generate
✗ dist/cli-bundle.js was NOT created by build:cli (esbuild silently failed?)

This is the ts-rs binding generation step (Rust→TS) for continuum-core failing with exit=null signal=null (process killed, no exit code captured — likely OOM, missing toolchain, or rustc panic). Same failure signature on every canary push since at least 2026-06-10 — checked runs at canary SHAs c109b069, 46832b47, 2a4b996f, 706b623c, d39241ce, 74f8be29, a0149e4c, 14c3e38c, 0fd01a40, dce4b0d1, 8fbc2606, f022f61a. All carl-install-smoke runs on canary in the past two days have failed with this same ❌ Failed: exit=null signal=null from the same ts-rs step.

Verdict: not caused by this PR; rerun won't help. The actual underlying break (likely related to the substrate-first repo layout migration in 2cb63e019 or a missing rustc on the smoke runner) is a separate fix and the smoke gate is currently red across the board. This PR should not be blocked on it, but the bot result remains red until the canary-wide break is fixed.

Summary

NOT APPROVED pending the BLOCK on the #1608 conflict. The script logic (CUDA detection, Git Bash guard, node/npm PIPESTATUS check, rust-toolchain.toml pin) is broadly sound — but the firewall rule is being added to code that the same author has already moved to delete in a parallel PR for malware-pattern reasons, and the firewall rule itself is over-scoped (-Profile Any). Decide #1608 first, then this becomes a tidy 3-NIT review.